-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[3/n] Enable validation composability and add composable single singer validation and tests #96
Conversation
cc54fc2
to
e0b605f
Compare
/// | ||
/// - This validation supports composition that other validation can relay on entities in this validation | ||
/// to validate partially or fully. | ||
contract EcdsaValidation is IEcdsaValidation, BasePlugin { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you clarify how this plugin is different from SingleOwnerPlugin?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The plan is to delete SingleOwnerPlugin
after this as it essentially supports a subset feature of EcdsaValidation
.
The features of EcdsaValidation
is in the docs above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think SingleOwnerPlugin has one other feature that EcdsaValidationPlugin doesn't support, which is contract owners via ERC-1271. That could be worth keeping it as the primary plugin, and updating it to be composable maybe? Wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EcdsaValidation
supports contract owners via ERC-1271 too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, sorry I missed that. In that case, isn't Single owner a more applicable name than ECDSA? Since it's not always ECDSA?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmmm, what do you mean? What could be an owner for SingleOwner that cannot be a signer for EcdsaValidation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant "SingleOwnerPlugin" is possibly a more fitting name. Via 1271, the signature validation is no longer just ECDSA (using ecrecover
), because the owner contract can implement any type of check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha. Good point. Maybe SingleSigner
is a bit more fitting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But then why are we recreating it in a new plugin contract, rather than updating SingleOwnerPlugin, if it's doing the same thing? I think we're one line away from equivalence, with the update to userOp.sender
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are very similar in the end (each func will need some update). Creating the validation and add tests was a lot easier for the development process than updating at the time.
Also it is a minor repo structure improvement with validation v.s. owner folder.
With PR [4/n], it does not matter how we get to here, right?
test/utils/TestConstants.sol
Outdated
@@ -2,3 +2,4 @@ | |||
pragma solidity ^0.8.25; | |||
|
|||
uint32 constant TEST_DEFAULT_OWNER_FUNCTION_ID = 0; | |||
uint32 constant TEST_DEFAULT_VALIDATION_ID = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not reuse? Left a comment up on the stack about renaming the above from TEST_DEFAULT_OWNER_FUNCTION_ID
to TEST_DEFAULT_OWNER_ENTITY_ID
.
@@ -27,6 +28,7 @@ interface IValidation is IPlugin { | |||
/// @param data The calldata sent. | |||
/// @param authorization Additional data for the validation function to use. | |||
function validateRuntime( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for updating these other two validation functions - with this, we should have full composability across all of the different types of validation functions.
3c43b10
to
7685790
Compare
if (IValidation(plugin).validateSignature(entityId, msg.sender, hash, signature[24:]) == _1271_MAGIC_VALUE) | ||
{ | ||
if ( | ||
IValidation(plugin).validateSignature(address(this), entityId, msg.sender, hash, signature[24:]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure if this should be addressed in this PR, but if the return values are _1271_MAGIC_VALUE
or _1271_INVALID
, would prefer to just remove the if/else part and do return IValidation(plugin).validateSignature(address(this), entityId, msg.sender, hash, signature[24:])
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's preferable to do the equivalence check before returning, because then we can absorb any bad values that are valid bytes4
types but aren't _1271_MAGIC_VALUE
or _1271_INVALID
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mmm from the spec, returning anything thats not _1271_MAGIC_VALUE
should be considered invalid. Don't feel super strongly about this, just a LOC reduction maxi
/// @inheritdoc IPlugin | ||
function onUninstall(bytes calldata data) external override { | ||
// ToDo: what does it mean in the world of composable validation world to uninstall one type of validation | ||
// We can either get rid of all SingleSigner signers. What about the nested ones? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we have to support the flow of getting rid of 1. Use case would be something like revoking 1 dapp session key by uninstalling the validation for that entity. Open to having a global "uninstall all" type of feature though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with Adam on reusing TEST_DEFAULT_VALIDATION_ID
if possible, otherwise LGTM
Update interfaces to support validation composability.
Add an ECDSA validation plugin and tests